This invention relates to a computer system for generating a system model, particularly but not exclusively to generation of a processor model.
There are two approaches commonly taken when implementing performance models of devices. The first is to produce a low level model of each component of the device and then connect up these component models to produce a complete simulation. This activity may be performed in numerous ways, for example, using a hardware description language such as VHDL or Verilog. The main benefit of this is that synthesis techniques for these languages are quite mature, making it possible to generate silicon directly from the description. Another example is a conventional programming language such as C/C++. The main benefits of taking this approach are that models tend to run quicker than VHDL/Verilog simulations, will typically run independently of any proprietary simulation environment (which may be essential if the model is to be used by customers) and will still integrate quickly and cleanly into any proprietary environment in which it is required. A further example is a graphical modelling tool, such as CAE-Plus""s Archgen. This has the benefit of being able to produce reasonably fast C models, but also generate VHDL/Verilog which can be used when a path to synthesis is required.
The main failings of this strategy are as follows.
It is a labour intensive approach, the cost of which is difficult to justify unless the model itself forms part of the design flow from architecture to silicon (as is typically the case for a VHDL/Verilog model say). It certainly makes no sense to try and develop, maintain and keep consistent two low-level models, say one written in C and the other in VHDL (though this is frequently attempted).
The model is functionally useless until it is virtually complete, that is, it is unlikely that the model will be able to run any benchmark code until very late in the design process.
The production of such models is totally dependent upon the complete (micro)architecture of the chip having been specified, and must track any changes to this specification. Again, this means that the model will turn up very late in the process.
Not only must the performance model track changes in the (micro)architecture specification it must also track the iterations in the architecture specification.
This late delivery of the model means that, although it should be of use for performance verification of the device, it will provide no support for the many activities which would benefit from the existence of early performance models.
The second approach uses a technique called trace driven simulation. This involves taking an instruction trace of a piece of code run on the functional simulator and feeding this to a model of the device. The main problems with this technique are that it is inevitably imprecise as it is based on imperfect information, for example, the performance model never has any visibility of instructions partially executed on any mispredicted path. Moreover, this technique cannot be used during any system performance modelling as the post-mortem nature of trace simulation means that the model cannot react to its environment.
It is an aim of the invention to mitigate or reduce these problems.
According to one aspect of the present invention there is provided a method of operating a computer to generate electronic data defining a system model, the method comprising: loading into the computer a class definition defining functional objects which are processed by the system, the definition including a set of functional methods to which the object is subjected by the system and a set of locations for members representing the object; executing on the computer a model execution program which calls the class definition for each object, invokes one of the functional methods and loads the locations of the entry with state information depending on the functional method to create a functional component; loading said functional component into an electronic storage medium wherein; and modifying the state information of the functional component in dependence on a subsequently invoked functional method by the model execution program.
Another aspect of the invention provides a computer system operable to generate electronic data defining a system model, the computer system comprising: a memory for holding class definition defining functional objects which are processed by the system, the definition including a set of functional methods to which the object is subjected by the system and a set of locations for members representing the objects; a processor for executing a model execution program which calls the class definition for each object, invokes one of the functional methods and loads the locations of the entry with state information depending on the functional method to create and modify functional components; and an electronic storage medium in which said functional components are stored and modified to generate the system model.
In the example described herein, the system is a processor and the objects are instructions to be executed by the processor.
At the heart of the invention is the separation of the function of the device from its performance. This is achieved by generating the functional model in such a way that its individual components are suitable for re-use within a performance model. For implementing a performance model, a timing method can be associated with each functional component. Note that this does not usually require specific knowledge of a particular implementation. For example, when developing a functional model of a processor, a functional component for execution of an instruction is arranged to read its source operands and write any results to its destination operands, rather than modify a register file directly. Thus, the instruction state (the destination operand result) is decoupled from the processor state (the register file). This arrangement means that in a performance model of a simple pipeline (with fetch, decode, execute, writeback phases) register forwarding (a feedback loop from the output of the execute phase back to its input) can be implemented by copying a result operand from an instruction which has just executed to any dependent operands in the next instruction to be executed.
The model can be refined during the project, becoming ever more cycle-accurate until, if required, it exhibits precisely the same timing behaviour as the design. This gives flexibility to trade-off accuracy against time/cost.
As performance models are derived from functional models they always incorporate the required functionality, for example executing code. Moreover, they can track, virtually automatically, any changes in the architectural specification. As the model is not intended as the basis for any synthesis it is possible to perform the modelling at a higher level of abstraction. This allows the environment to support explorations of the (micro)architectural design space without a complete (micro)architecture specification and implementation having to be produced.
This early delivery of performance models incorporating functionality makes them amenable to supporting many activities which would otherwise have to rely on far less empirical techniques. For example cost vs. benefit trade-offs; (micro)architecture, such as explorations of various dynamic and static branch prediction techniques; toolchain optimisations, particularly instruction scheduling, and algorithm development; production of marketing data from running standard and customer benchmarks; and validation, that is, ensuring a particular design can meet the demands of the market to which it is targeted.
For a better understanding of the present invention and to show how the same may be carried into effect, reference will now be made by way of example to the accompanying drawings.